home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / general.programming / comp.lang.c_13324_000020.msg < prev    next >
Encoding:
Text File  |  1994-11-27  |  3.3 KB  |  87 lines
  1. Path: dd.chalmers.se!news.chalmers.se!sunic!pipex!howland.reston.ans.net!darwin.sura.net!nntp.st.usm.edu!whale.st.usm.edu!not-for-mail
  2. From: chambles@whale.st.usm.edu (John William Chambless)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: `char *a="text"` same as `char a[] = "text"` ??
  5. Date: 4 Apr 1994 10:52:33 -0500
  6. Organization: The Greys
  7. Lines: 73
  8. Message-ID: <2npd41$29pb@whale.st.usm.edu>
  9. References: <sstasuke.49.0004A173@wtc34a.daytonOH.ncr.com> <2midmf$5e0@dawn.mmm.com> <2mjvo8$cju@chico.staf.phil.ruu.nl> <1994Apr1.133445.6009@hns.com>
  10. NNTP-Posting-Host: whale.st.usm.edu
  11. Summary: Idiots are always right.
  12. Keywords: RTFM clue ANSI lvalue
  13.  
  14. In article <1994Apr1.133445.6009@hns.com>, Joe Dunn <jdunn@hns.com> wrote:
  15. >In article <2mjvo8$cju@chico.staf.phil.ruu.nl>, hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
  16. >|> First of all: there have already been several correct follow-ups to the
  17. >|> original question. If you're *not* sure about the correctness of your reply,
  18. >|> you might consider not posting it...
  19.  
  20. >you should follow your own advice...
  21.  
  22. ROTFL!
  23. The irony of your reply is classic considering how totally incorrect
  24. your post is.
  25.  
  26. >this is absolutely wrong!! you can modify a exactly like this. only in c++
  27. >if you declare the pointer to a string a constant can you not modify the string
  28.  
  29. Oh, really? Wow, you should immediately notify Dennis Ritchie, Brian Kernighan,
  30. and the ANSI comittee on C! They ALL have it wrong!
  31.  
  32. >a literal string is nothing more than an array. try it:
  33.                                                 ^^^^^^^^
  34. Oh, okay. Since it works on YOUR copy of the FooBar WhizBang
  35. C compiler on _your_ machine, it MUST be valid code!
  36.  
  37.  
  38. >        char *a = "text";
  39. >        printf("a = %s\n",a);
  40. >        a[1] = 'f';
  41. >        printf("a = %s\n",a);
  42.  
  43. *deep sigh*
  44. One more time, class--from the top:
  45.  
  46. From the ANSI/ISO C Standard, 6.5.7:
  47.  
  48.     "...the declaration
  49.  
  50.     char *p = "abc";
  51.  
  52.     defines p with type "pointer to char" that is initialized to
  53.     point to an object with type "array of char" with length 4 whose 
  54.     elements are initialized with a character string literal. If an
  55.     attempt is made to use p to modify the contents of the array,
  56.     the behaviour is undefined."
  57.  
  58. The fourth paragraph of section 5.5 of K&R2 says the same thing.
  59.  
  60. If you're unsure what "undefined" means, it's in Annex G of the standard,
  61. or you can read all about it in the comp.lang.c archives.
  62. >
  63. >sorry, no difference. in a real operating system that does not have the
  64. >segmented memory of DOS, code space and data space, these definitions can
  65. >be used interchangaebly. 
  66.  
  67. The OS is irrelevant.
  68. The fact is  that some compilers will accept bletcherous code such as
  69. your example, but the Standard does not require them to.
  70.  
  71. Run lint on your example, and see what it says.
  72.  
  73. > Naturally, when DOS grows up and becomes a true 32 bit operating system
  74. > then we can all go back to using the statements interchangeably.
  75.  
  76. Why use them interchangably?
  77. Most of us have already solved the problem  by learning to write
  78. ANSI-compliant code. Code that depends on the quirks of a particular
  79. compiler is dangerous.
  80. >
  81. > 
  82.  
  83.  
  84. -- 
  85. *  Billy Chambless                  University of Southern Mississippi
  86. * "IBM is not a necessary evil.  IBM is not necessary."  -- Ted Nelson
  87.